home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / ACORNUSERS / EMULATOR / EMUL6502 / !help next >
Text File  |  1998-08-27  |  12KB  |  229 lines
  1. ---------------------------------\---------------------\---\-\   Alain BROBECKER
  2.    emul6502   v0.05  (25aug1998)  >  © Alain BROBECKER  >   > >  rte de Dardagny
  3. ---------------------------------/---------------------/---/-/    01630 CHALLEX
  4.                                                                       FRANCE
  5.                                                             abrobecker@yahoo.com
  6.                                             http://www.cybercable.tm.fr/~brooby/
  7.  
  8.  
  9.                Contents ---->-->->> 1. Legalities
  10.                                     2. Verbose Mode OFF
  11.                                     3. Debugger keys & controls
  12.                                     4. Limelight
  13.                                     5. Technical details
  14.                                     6. History
  15.  
  16.  
  17.  
  18. ------------------------------>  1. Legalities  <-------------------------------
  19.  
  20.   * YOU CAN FREELY COPY THIS SOFTWARE AS LONG AS YOU LEAVE FILES UNALTERED,
  21.     AND DON'T USE IT FOR COMMERCIAL PROFIT (PDL SHALL CONTACT ME FIRST).
  22.   * PLEASE NOTE THAT YOU USE IT (or not =) AT YOUR OWN RISKS! (maybe i shall
  23.     mention i do use it at my own risks =)
  24.   * COMMENTED SOURCECODE IS PROVIDED FOR INSPIRATION TO ALL CODERS OUT THERE.
  25.     USAGE OF PARTS OF CODE OR IDEAS IS ENCOURAGED AS LONG AS YOU CREDIT ME AND
  26.     YOUR PRODUCT IS FREEWARE.
  27.  
  28.  
  29.  
  30. --------------------------->  2. Verbose mode OFF  <----------------------------
  31.  
  32.    * To use it, set current directory to its directory and double click
  33.      on the emul6502 program, you will then be faced with the debugger.
  34.      Go on to section 3 to know how to handle this.
  35.    * To run another program, edit the sourcecode and change filename in f$.
  36.      Files to be run with emul6502 must begin with two reversed words (rw)
  37.      containing load & exec adresses, followed by the 6502 machine code.
  38.    * All 6502 programs are provided with source, too. Look at their sourcecode
  39.      to know what they do. Use asm6502 to assemble them.
  40.    * Intended for programmers, anyway only people able to face a debugger
  41.      without wondering what all those numbers are can bear it.
  42.    * The emul6502 project will serve as basis for my forthcoming ATOM emulator
  43.      called ATOMbomb, so don't be surprised to find some reference to this
  44.      fantastic machine here!
  45.    * Look at the technical details for more infos.
  46.  
  47.  
  48.  
  49. ----------------------->  3. Debugger keys & controls  <------------------------
  50.  
  51.   Debugger screen has 3 windows, one for 6502 disassembly and two for memory
  52. dumps. The active one has its name highlighted. There also is a dump of the
  53. 6502 registers. The adress of PC is highlighted when displayed in disassembly
  54. window, breakpoint adress and instruction are redlighted.
  55.  
  56.   Tab       Change active window.
  57.   Arrows    In memdump left&right for byte displacement, up&down for eight.
  58.             In disassembly up&left&right for one byte displacement, down for
  59.             one instruction displacement.
  60.   W (alk)   Execute one instruction.
  61.   R (un)    Execute until next BRK instruction. If execution time is more than
  62.             one cs, it will be displayed with nb of 6502 cycles and speed.
  63.   S (kip)   Skip instruction.
  64.   B (rk)    Set/unset the breakpoint. Only one brkpt authorized.
  65.   A (dress) Enter new adress for active window.
  66.   E (dit)   In memdump modify byte at window adress.
  67.             In disassembly modify byte/word in given register.
  68.   ESC       sounds mysterious.
  69.  
  70.  
  71.  
  72. ------------------------------>  4. LimeLight  <--------------------------------
  73.  
  74. The following people (listed alphabetically) provided me with precious help,
  75. comments and/or support during the project:
  76.    * Frederic Elisei (aka ArmOric/Arm's Tech), always with dirty and fast
  77.      code ideas in mind, whatever the subject. Too bad he's the boss in
  78.      Arm's Tech and wants us to be productive! =)
  79.    * Benoit Gilon, author of the !Woz (apple][) and Trash (TRS80) emulators,
  80.      has shown interest in emul6502.
  81.    * David Sharp, the one behind the very good Acorn emulation page, and
  82.      incidentally writing a NES emulator. We had lotsa chat about our
  83.      respectives 6502 emulators.
  84.  
  85. Some other peoples have put 6502 or ATOM related sourcecode in public domain
  86. (so do i, see legalities above), and this proved usefull! Thanx pals.
  87.    * Paul Clifford, author of the PC Engine emulator for RiscPC.
  88.    * Frans Faase, author of an ATOM emulator in C.
  89.    * Wouter Ras, author of an ATOM emulator in 80x86 assembly.
  90.  
  91.  
  92.  
  93. --------------------------->  5. Technical Details  <---------------------------
  94.  
  95. 1. Memory adressing
  96. ~~~~~~~~~~~~~~~~~~~
  97.   Since the Acorn ATOM emulator is a bank-mapping free computer i didn't cared
  98. about it, but i think emul6502 would be able to cope with this anyway, as long
  99. as you don't have to check for page change for the ePC within an instruction
  100. (which sounds fair). To achieve bank mapping implementation you'll have to
  101. modify code in the FNread_mem and FNwrite_mem macros (i will have to change
  102. them anyway for I/O operations) and in the jump/jsr/rts/rti emulation. Maybe
  103. even in the branch emulation, though it sounds improbable.
  104.  
  105.   I also plugged my c64 and played around with an asm to test some adressing
  106. modes' features of the 6502 (the c64 has a 6510, but i expect it to react the
  107. same). Here's what i found ([] means byte found at adress):
  108.             ldx #128:lda z,128,x ;a=[0], not [256]
  109.             ldx #128:lda (128,x) ;a=[[1]*256+[0]], not [[257]*256+[256]]
  110.             ldx #0:lda (255,x)   ;a=[[0]*256+[255]], not [[1]*256+[0]]
  111.             ldy #0:lda (255),y   ;a=[[0]*256+[255]+y]
  112. So i believe correct adressing are:
  113.             z,M,index adr=([ePC]+index)AND&ff
  114.             (M,x)     adr=[([ePC]+x)AND&ff]+[([ePC]+x+1)AND&ff]*256
  115.             (M),y     adr=[[ePC]]+[([ePC]+1)AND&ff]*256+y
  116.   But i bet most programs won't need the emulator to be that precise, so i
  117. added the "ExactAdr" boolean, and when set to FALSE the above modulos are not
  118. cared of, neither is the case when we bypass the &ffff adress limit in indexed
  119. adressing modes. When set to TRUE all this modulos protections will be enabled.
  120.   The same kind of statement as above applies: i don't check if ePC bypasses
  121. &ffff since it is most unlikely the ePC will be that high in memory (the 6502
  122. has interrupt/reset vectors at &fffa-&ffff).
  123.  
  124.  
  125. 2. BCD arithmetic
  126. ~~~~~~~~~~~~~~~~~
  127.   First i would like to thank Paul Clifford for releasing his source to the
  128. PC engine emulator, since my 6502 docs didn't cover the subject it proved
  129. very valuable. I was even able to optimise my code thanks to his tricks (and
  130. i'm now faster than you Paul =).
  131.  
  132.   The BCD mode is incorrectly emulated! No, don't be afraid, just let me
  133. explain... I tested the ADC and BCD for all possible case with BCD numbers in
  134. entry, and the result are good, with ZC flags correctly set, and N probably
  135. too, though it is irrelevant. At least i think so (i have no docs, only my
  136. common sense). But there are no chances the V flag is set correctly (he is
  137. irrelevant, too) and i don't know how the BCD mode behaves when provided with
  138. non-BCD numbers.
  139.   But i think those are no problem, since the coder who will use non-BCD
  140. numbers on purpose shall be so tricky his program won't work anyway. So i
  141. decided not to bother more for the moment...
  142.  
  143.   Another point to know about BCD is that it is really RARE! I have been told
  144. a programmer had is NES emulator up and running with BCD emulation totally
  145. wrong (he spoke about 1+9=70 =), and discovered it only when testing the BCD
  146. ops himself. In the same sort of idea, i trapped the SED instruction in the
  147. ATOM roms, and dicovered the BCD mode isn't used during the 10000 sycles the
  148. startup lasts (but will test more soon).
  149.  
  150.   To implement BCD mode i decided to use a dual HEX/BCD opcode decoding table,
  151. and switch between them when a SED or CLD is encountered. This doesn't cost
  152. processing power if switching is rare (unlike testing for BCD mode before
  153. each ADC/SBC instruction like Paul does). If it were not the case i think i
  154. would have removed BCD emulation completely: the worst that could happen would
  155. be to have the score wrong in a game (some will say it is important =).
  156.  
  157.  
  158. 3. Some optimisations
  159. ~~~~~~~~~~~~~~~~~~~~~
  160.   Here are explanations to some optimisations you can find in the code and
  161. their respective authors. Some are missing, but you can have the detail in the
  162. history. Don't hesitate to contribute! =)
  163.    * Dave proposed to have the BDI flags stored in memory instead of mixed with
  164.      other flags in a register, since they are not used often. So setting all
  165.      flags now requires only a "mov F,pc,lsr #28", at the expense of extra
  166.      instructions in PHP,RTI,etc...
  167.    * ArmOric found a neat trick: if the V flag of ARM equals 0 when entering
  168.      FNnext_NZC, we can use "orr F,F,r15,lsr #28" to set flags. In a 6502
  169.      shift operation the last ARM arithmetic instruction is "subS T,T,#time"
  170.      which sets V to 0, so the trick works. Alas in a 6502 comparison, the
  171.      last ARM arithmetic instruction is "cmp A,byte,lsl #24", and the V bit can
  172.      be set, so i had to write FNnext_NZC2.
  173.    * I found a trick to have the ARM flags set to what the 6502 flags should be
  174.      after an ADC: put the 6502 register in upper byte of an ARM reg, fill the
  175.      rest with ones, so the entry carry will be propagated to first bit of
  176.      6502's reg, and flags are set correctly after ARM's ADC, except the Z flag
  177.      if entry carry is 0. The latter problem is solved with "bicS reg,reg,mask"
  178.      where mask=&00ffffff, which leaves C & V unaffected (C because we have
  179.      "lsl #0" and V because this is a logical op), and will set N & Z correctly.
  180.      So if we keep flags in NZCV format instead of 6502's one, we will have
  181.      very fast flag handling.
  182.  
  183.  
  184.  
  185. -------------------------------->  6. History  <--------------------------------
  186.  
  187. v0.05  (25aug1998)
  188.    * Emulator totally reorganised and cleaned up.
  189.    * All documented instructions now implemented, even BCD ones.
  190.    * All adressing modes now implemented, even plugged my c64 to check side
  191.      effects of some adressing modes. Added the "ExactAdr" flag to tell
  192.      wether we shall care or not about those side effects.
  193.    * I gained one instruction in the BCD version of ADC by looking at Paul's
  194.      code (thanx!, my routine now is two instructions faster than yours =).
  195.      In the same way i got inspiration for the BCD version of SBC, and once
  196.      again it is faster. =)
  197.    * Squashed bugs in CPX, CPY, PLP0.
  198.    * Small bug killed in debugger's skip procedure.
  199.    * The ATOM roms seems to behave well. The "ACORN ATOM" message and the
  200.      prompt are copied at adress &8000 (graphics ram) as should be.
  201.    * Wrote some "self-checking" programs for easier debugging.
  202.  
  203. v0.04b (11aug1998)
  204.    * Implemented Dave's idea: putting BDI flags in memory.
  205.    * Implemented the dual hexa/BCD opcode decoding table.
  206.    * Due to those major changes, many routines (SED, PHP...) were rewritten.
  207.    * ROL2 & ROL3 rewritten (previous versions were wrong).
  208.  
  209. v0.03b (16jun1998)
  210.    * Implemented ArmOric's trick for FNnext_NZC.
  211.    * ArmOric and i gained one instruction in ROL0.
  212.    * Bug squished in ROR2 & ROR3: Z bit wasn't set correctly.
  213.  
  214. v0.02b (14jun1998)
  215.    * Implemented ArmOric's code for ROR, no more limited to accumulator. This
  216.      gained two cycles in ROR0 mode and eased things a lot for ROR2 & ROR3.
  217.    * Rectified wrong reference of ROR3 in opcode & disassembly tables.
  218.    * Removed bugs in ROL3, PHP0 & PLP0.
  219.  
  220. v0.01b (07jun1998)
  221.    * Only zero page adressing mode.
  222.    * Some instructions are missing (BIT, JMP, JSR, RTS, RTI), no BCD mode.
  223.    * ROR is limited to accumulator.
  224.    * Trick for flags handling in ADC/SBC implemented.
  225.    * Provided with some sources it can run.
  226.    * 6502 debugger complete.
  227.  
  228. Project started 29may1998
  229.